
Symmetric encryption in Swarm is using a slightly modified version blockcipher in counter mode.

The encryption seed for the chunk is derived from the master seed if given, otherwise just generated randomly. 

The reference to a single chunk (and the whole content) is the concatenation of the hash of encrypted data and the decryption key (see \ref{def:chunk-reference}). This means the encrypted Swarm reference (64 bytes) will be longer than the unencrypted one (32 bytes). When a node syncs encrypted chunks, it does not share the full references (or the decryption keys) with the other nodes in any way.  Therefore, other nodes will be unable to access the original data, or in fact, even to detect whether a chunk is encrypted.

\begin{definition}[Chunk encryption/decryption API]\label{def:encrypt}
\begin{lstlisting}[language=buzz1]

// generate key for a chunk
define encryption.key for chunk
    ?with @seed [segment.size]byte
as
    return crypto/random key if no @seed // generate new 
    hash @seed and @chunk address

define function encrypt chunk
    with key 
as   
    @segments = @chunk data pad to chunk size
        each segment size 
            go crypt at @i++ with @key 
    @span = chunk span crypt at branches with @seed 
    @payload = wait for @segments 
        join
    chunk{ @span, @payload } 


define function decrypt chunk
    with key 
as       
    @span  = @chunk span 
        crypt at branches with @key 
    @segments = chunk data to @span payload.length
        each segment size 
            go crypt at @i++ with @key
    @payload = wait for @segments 
        join
    chunk{ @span, @payload } 

\end{lstlisting}
\end{definition} 
       
        
Encrypted Swarm chunks are not different from plaintext chunks and therefore no change is needed on the P2P protocol level to accommodate them. The proposed encryption scheme is end-to-end, meaning that encryption and decryption is done on endpoints, i.e., where the http proxy layer runs. This has an important consequence that public gateways cannot be used for encrypted content. On the other hand, the apiary modular design allows for client side encryption on top of external  APIs while proxying all other calls via the gateway.

